Operations Control

System and Message Overviews

Document Version: 6.2

Date: November 1, 2017

Document Revision History

The following revision history table reflects all substantive changes to this document since original publication.

Table Of Contents

1 Introduction

This document defines the interfaces which govern the interchange of data between an Operations Control system and other systems within an Airline Operation Center (AOC).  Each AOC interface is represented by a message described in an associated XSD (XML Schema Definition). The XSD defines and enforces the required, optional, and conditional data that can be included in a message.

Operations control systems are used to manage airlines’ operational schedules. This includes such activities as creating flight legs, managing cancellations, deletions and diversions, and communicating flight status. Operations control systems are typically concerned with flight legs, as opposed to complete flights, which are managed by scheduling systems.

1.1  Audience

The intended audience for this document includes existing and potential Jeppesen customers, integration partners, and personnel with roles associated with application architecture, application development, system testing, implementation, and application support within Operations Control.

1.2  Scope

This document discusses the Operations Control messages currently supported by the Jeppesen Solution Integrator. Each message description includes the following:

• Overview for common message uses within an AOC
• Message Version Summary listing all available versions of each message
• Links to the message specifications including direct links to XSD documentation, where you can explore the XSD hierarchy and interface specifications in a navigable HTML format
• Links to the XSD source code
• Links to sample XML messages for each AOC message

Other data interfaces or formats not included in this document will be considered custom and not supported.

1.3  XML Schema/XSD

The XML schema for this ICD is published in the following file: OperationsControl.xsd

2  Message Summary

Table 2-1 lists the messages that can be sent or handled by the application.

Table 2-1 Message Summary

3 AOC Interface Messages

The following messages are processed by the Operations Control system.

3.1 OC001 - Create Flight Leg

3.1.1  Message Overview

The Create Flight Leg message is used to create scheduled flight legs. Multiple flight legs can be created in a single message. This message deals with scheduled fields such as scheduled departure time and scheduled arrival time; it is not concerned with actual data, which is handled by other Operations Control messages.

3.1.1.1 Creating a new flight leg

The Create Flight Leg message can be used to create a single flight leg between two cities. Note that the OC001 message fields only contain information related to the scheduled flight. Flight actuals will be included in other messages such as Delay and Divert Flight Leg. Note also that although an equipment type is required, the specific aircraft identification is not required. Actual tail numbers can be assigned to a leg later using the Aircraft Assignment message.

3.1.1.2 Creating a multi-leg flight

When creating multiple legs using a single message, the same fields are required for each leg as when creating a single leg. This message includes a repeating group, which allows the create flight information to be repeated for as many legs as necessary.

3.1.1.3 Creating an irregular operation flight

The Create Flight Leg message can also be used to create irregular operations legs. Irregular operation legs are any flights other than planned revenue-generating flights. There are three common types of irregular operations:

• Continue
• Ferry
• Position

3.1.1.3.1 Continue

When a flight is diverted to another airport, due to weather or mechanical issues, scheduling systems typically generate a “continuation” leg from the diversion point to the leg’s original point of arrival (poa). In the case where a continuation leg is not automatically created, a new flight leg needs to be created. This new flight leg must set the Irregular Operations field to continue.

Step four in Figure 1 shows when the irregular operation of type “continue” should be used.

Figure 1. Sample create continue leg scenario.

3.1.1.3.2 Ferry

Ferry flights are non-revenue generating flights used to move an aircraft from one location to another, usually for purposes related to maintenance. Ferry flights can be scheduled or unplanned as a result of mechanical issues. Figure 2 shows an example situation for a ferry flight.

Figure 2. Sample create flight ferry scenario.

3.1.1.3.3 Position

Position flights are used to move an aircraft from one location to another in order to enable a revenue flight. Position flights are most common for charter and cargo flights.

For example, Jeppesen Airlines has a contract with the NBA to fly the Denver Nuggets to their game locations. Jeppesen Airlines flies the Nuggets from Denver to Los Angeles, where the Nuggets plan to remain for two days. In the meantime, JP uses the aircraft to fly a business party one-way from Los Angeles to San Francisco. The plane is then flown (as a Position flight) from San Francisco to Los Angeles in time to return the Nuggets to Denver. Figure 3 shows an example situation for a positioning flight.

Figure 3. Sample create flight position scenario.

3.1.1.4 Additional Notes

The following notes should be considered when using this message:

• The equipmentCode field can include either ICAO or IATA codes. 
• This message is used to specify the schedule, not the actuals.

3.1.2  Message System Flow

This message interacts with the systems as shown in Figure 2.

Figure 4. OC001 message system flow

3.1.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.2 OC002 - Cancel Flight Leg

3.2.1  Message Overview

This message is used to cancel an existing flight leg.

When a particular flight leg is no longer needed or no longer possible for reasons related to under-bookings, severe weather, and mechanical issues, it can be deleted or canceled. Deletion and cancellation records can be used by the carrier to fine-tune their schedules.

Flight legs must be canceled if they are within a certain number of days of the scheduled departure date. US carriers must cancel flights within seven days of the scheduled departure. Canceled flights must be reported to the Department of Transportation.

3.2.1.1 Canceling a single flight leg

Carriers may decide to cancel a flight for reasons related to weather, under-bookings, and mechanical issues. For example, Jeppesen Airlines has two scheduled flights from LAX to SFO, departing ten minutes from each other. The first flight is not completely booked and there are very few bookings on the second flight. Jeppesen Airlines moves passengers from the second to first flight and then cancels the second flight.

3.2.1.2 Additional Notes

The following notes should be considered when using this message:

• To cancel a flight leg, only the flight key is required.
• Although the <reason> field is optional in this message, carriers are encouraged to capture the cancellation reason for reporting purposes.
• Deletes can be used instead of cancels when the flight is removed a certain number of days before the scheduled departure. This can be advantageous to carriers because deletes do not have to be reported to the Department of Transportation.

3.2.2  Message System Flow

This message interacts with the systems as shown in Figure 5.

Figure 5. OC002 message system flow

3.2.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.3 OC003 - Delete Flight Leg

3.3.1  Message Overview

This message is used to delete an existing flight leg.

When a particular flight leg is no longer needed or no longer possible for reasons related to under-bookings, severe weather, and mechanical issues, it can be deleted or canceled. Deletion and cancellation records can be used by the carrier to fine-tune their schedules.

If an airline determines a future flight leg is not need, they can delete the flight. US carriers can delete a flight up to seven days before departure. Anything closer to the scheduled departure date must be canceled, rather than deleted. Deletions remove flights from the scheduling system and are not reported to the Department of Transportation.

3.3.1.1 Deleting a single flight leg

Carriers may decide to delete a flight if they anticipate a future flight will be under-booked or if they plan to perform maintenance on a number of aircraft, thus reducing their capacity. 

For example, historical data shows that Flight 2245 from LAX to SFO never fully books on December 25 (Christmas day). The carrier sends a delete message for that specific flight leg.

3.3.1.2 Additional Notes

• To delete a flight leg, only the flight key is required.
• Although the reason field is optional, carriers are encouraged to capture the deletion reason for reporting purposes. The actual reason in the message will consist of a four-character code and optional text explanation.
• Use deletes instead of cancels when the flight is removed a certain number of days before the scheduled departure. This can be advantageous to carriers because deleted flights do not have to be reported to the Department of transportation.

3.3.2  Message System Flow

This message interacts with the systems as shown in Figure 6.

Figure 6. OC003 message system flow

3.3.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.4 OC004 - Reinstate Flight Leg

3.4.1  Message Overview

This message is used to reinstate a flight leg that has been deleted or canceled.
In order to reinstate a flight leg, the scheduling systems must have placed a cancel or delete indicator flag on the flight legs during the cancel/delete operation. If the record was removed from the system using a hard delete, then the reinstate is not an option and a new flight leg must be created.

3.4.1.1 Reinstating a deleted or canceled flight leg

If a carrier cancels or deletes a flight, but then decides that they, in fact, want that flight to occur, then they can simply reinstate it. For example, Flight 1234 from LAX to SFO is canceled due to aircraft mechanical issues. A quicker-than-anticipated repair puts the aircraft back into service. Flight 1234 is reinstated.

3.4.1.2 Additional Notes

The following notes should be considered when using this message:

• Although the <reason> field is optional in this message, carriers are encouraged to capture the reason for reinstating the canceled or deleted flight for reporting purposes.

3.4.2  Message System Flow

This message interacts with the systems as shown in Figure 7.

Figure 7. OC004 message system flow

3.4.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.5 OC005 - Divert Flight Leg

3.5.1  Message Overview

This message is used to divert a flight leg. This message can also be used to create a continuation leg.  This message changes the actual point of arrival.

A diversion is a flight that is required to land at a location other than the original destination for reasons beyond the control of the pilot/company. Diversions may be caused by such things as severe weather or equipment issues.
There are two types of diversions:

• Unplanned Diversion – diversion that occurs after takeoff.
  Example: A flight from LAX to SFO receives a report of bad weather in San Francisco while en route, and the flight is diverted to Sacramento. 
• Planned Diversion – diversion that occurs before takeoff.
  Example: A flight plan is calculated for LGA to LAX, accounting for a strong headwind. The flight plan calls for a stop (or diversion) midway for refueling.

The divert message is used in the following situations:

• Divert – point of diversion becomes the new POA.
• Divert and continue – flight automatically created from point of diversion to the original destination.
• Divert and hold – flight is held at the diversion point; a continue leg is not built.
• Planned diversion – a “divert-and-continue” diversion planned before takeoff.

3.5.1.1 Divert

Sometimes when a flight leg is diverted, a continue leg is automatically generated from the diversion point to the originally scheduled destination (poa). However, sometimes the diversion point becomes the new POA, as is illustrated in the following scenario. Note that this scenario applies to both en route and pre-departure diversions.

1. Flight leg diverted from original destination to new destination, changing the diversion point to the new POA.

Figure 8 shows a typical divert scenario.

Figure 8. Divert

3.5.1.2 Divert and Continue

Typically, when a flight leg is diverted, a continue leg is automatically generated from the diversion point to the originally scheduled destination (poa). A divert-and-continue uses the following process:

1. Flight leg diverted from original destination to new destination, changing the Actual POA of the leg.
2. A “continuation leg” is created from the diversion point to the original Point of Arrival (POA).

Figure 9 shows a typical divert and continue scenario.

Figure 9. Divert and Continue

Note that this message (OC005) contains information related to the continuation leg. The continue leg only requires that you send the new scheduled time of departure (std) and scheduled time of arrival (sta) for the leg from MCI to ORD. You do NOT need to send a “create flight leg” message (OC001) when using this message.

3.5.1.3 Divert and Hold

An airline might divert a flight to a new POA and then hold the flight at that location. In this case, a new leg is NOT automatically built from the diversion point to the final destination. Passengers would then be moved to different flights traveling to their desired destination, or a new flight leg would be created later with the Irregular Operation field set to “continue.”

Note: Divert-and-holds are less common than divert-and-continues. Continue legs to the final destination are typically built automatically with any diversion.

Figure 10 shows a Divert and Hold scenario.

Figure 10. Divert and Hold

Note: When using this approach, you will either need to send a “create flight leg” message (OC001) to build the flight leg to the originally planned destination, or arrange for through-passengers to get their destination by other means.

3.5.1.4 Planned Diversions

Diversions can happen before an aircraft leaves the ground. For example, a long flight from LGA to LAX is calculated the morning of the flight. When factoring in a strong headwind, the flight plan requires a refueling stop mid-flight. In this example, the flight diverts to DEN and then continues to LAX.
Figure 11 shows a planned diversion scenario.

Figure 11. Planned Diversion

Note that this message includes scheduling information (scheduledTimeDeparture and scheduledTimeArrival) for the continuation leg. Note also that the POA is not included in the continue leg information because the flight is still bound for LAX.

3.5.1.5 Additional Notes

• Most carriers will perform a “divert and continue” or “planned diversion” as explained above, automatically building the continuation legs. In the case where the flight cannot move from the diversion to the final destination along the “continue” flight leg (due to weather or mechanical issues), then the continue leg is canceled.

3.5.2  Message System Flow

This message interacts with the systems as shown in Figure 11.

Figure 12. OC005 message system flow

3.5.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.6 OC008 - New Origin Flight Leg

3.6.1  Message Overview

This message is used to change the actual point of departure of a flight leg. This message is used to change the actual point of departure (pod) from one airport to another airport in close proximity.

3.6.1.1 New Origin Flight Leg

This message is used to change the actual point of departure from one airport to another airport in close proximity.
For example, after taking off from Los Angeles, Flight 1234 (LAX to SFO to DEN) is notified of heavy fog in San Francisco and is diverted to Oakland, using the Divert Flight Leg message. A continuation-leg is created, changing the actual point of departure from SFO to OAK. The second leg of flight 1234 is now OAK to DEN.

3.6.1.2 Additional Notes

3.6.2  Message System Flow

This message interacts with the systems as shown in Figure 13.

Figure 13. OC008 message system flow

3.6.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.7 OC009 - Update Flight Leg

3.7.1  Message Overview

This message is used to update flight attributes that cannot be updated via the other leg management messages. This includes assigning or updating the Service Type and Route. The service type codes in this message are taken from the IATA manual.

Note:    This message is not used to update estimate or actual flight times, departure, or arrival data. See Related Messages box below for additional information.

This message interacts with the

3.7.2  Message System Flow

systems as shown in Figure 14.

Figure 14. OC009 message system flow

3.7.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.8 OC010 - Reschedule Flight Leg

3.8.1  Message Overview

This message is used to change the schedule times for a flight leg. This message changes the scheduled time of departure (std) and scheduled time of arrival (sta).

Note: This message can NOT be used to reschedule the first leg of a flight if it changes the date of departure. This would change the flight key. Instead, you must send a Change Flight Identifier message for the first leg and all down-leg flights. Then, after changing the flight identifier, you can send this message to reschedule one or more flight legs.

3.8.1.1 Changing the scheduled departure by a few minutes

This message can be used to change the STD and STA of flights. Carriers will typically send this message a few days or weeks before a flight to move its departure forward or back a few minutes.
For example, JEP Airlines consistently experiences slower than anticipated turn times when flying through DEN. They decide to push the scheduled time of departure back fifteen minutes for Flight 1234’s DEN to ORD leg. They send a Reschedule Flight Leg message to reschedule the STD and STA of the leg.

3.8.1.2 Special Case: Changing the scheduled departure to a new day

This message can NOT be used to reschedule the first leg of a flight if it changes the date of departure. This would change the flight key. Instead, you must send a Change Flight Identifier message (OC018) for the first leg and all down-leg flights. Then, after changing the flight identifier, you can send this message to reschedule one or more flight legs.
For example, the first leg of flight 1234 departs from LAX at 2330. A maintenance issue moves the departure time to 0005 the next day. The Reschedule Flight Leg message can NOT yet be sent because it would change the flight’s flight key. Instead, the airline sends the OC018 (Change Flight Identifier) message to change the flight identifier for this leg and all down-leg flights. Only then can the OC010 (Reschedule Flight Leg) message be sent to alter the flight times.  

3.8.1.3 Additional Notes

3.8.2  Message System Flow

This message interacts with the systems as shown in Figure 15.

Figure 15. OC010 message system flow

3.8.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.9 OC011 - Aircraft Assignment

3.9.1  Message Overview

This message is used to assign aircraft and/or equipment type to a flight leg.

When creating a flight leg, you are required to specify the type of aircraft (equipment type) for that flight. You do not, however, need to identify the specific aircraft until the day of the flight’s departure. This enables carriers to create schedules while retaining flexibility with actual fleet assignments and maintenance cycles.

Note: If the Aircraft ID is not included in this message, the receiving application will remove any previously assigned aircraft ID. 

Assign a specific aircraft to a flight

This message can be used to assign a specific aircraft to a flight. For example, JEP Airlines created Flight 1234 using a Boeing 777 equipment type. The morning of the flight, the dispatcher assigns aircraft ID “JP100A.”

Change the equipment type for a flight

This message can be used to change the equipment type for a single flight leg. For example, the Boeing 777 scheduled for Flight 1234 is grounded for mechanical reasons just before completing the last leg of its flight.  There is no other Boeing 777 available for the flight. JEP Airlines sends an Aircraft Assignment message to change the equipment type from 777 to 787, and uses an available 787 to fly the final leg.

Change the equipment type for multiple flight legs

This message can be used to change the equipment type for multiple flight legs. For example, JEP Airlines anticipates a low passenger volume on Christmas Day for all legs of Flight 1234. They decide to use a Boeing 767 rather than the 777. They send a single Aircraft Assignment message, and utilize the message’s repeating group to change the equipment type for each leg of the flight.

Figure 16 shows an equipment type swap for two multi-legged flights. A separate Aircraft Assignment message would be sent for each of the planes being swapped.

Figure 16. Equipment type change (swap) for multi-leg flight.

Change equipment type and assign an aircraft ID

This message can also be used to both change the equipment type and assign an aircraft ID. For example, the Boeing 777 (tail number JP100A) is grounded due to mechanical issues and there is not another 777 available for the flight. JEP Airlines sends the Aircraft Assignment message to:

1. Change the equipment type to an available 787.
2. Assign a specific aircraft identification number to the flight (example, JP230A).

Additional Notes

3.9.2  Message System Flow

This message interacts with the systems as shown in Figure 17.

Figure 17. OC011 message system flow

3.9.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.10 OC012 - Estimate Times

3.10.1  Message Overview

This message allows for update of any combination of the following estimated times:  ETD, ETO, EON, or ETA for a flight leg. It is highly recommended that if an estimated departure time (ETD/ETO) is updated, that at a minimum a new estimated time of arrival (ETA) also be provided.

This message is used to update the estimate times related to a flight leg. Though the reasons for sending this message vary, the message itself contains the same information: flight key, any updates to the estimate times, delay reasons, and additional textual information.

3.10.1.1 Update estimates due to delay

This message can be used to update the estimated time of departure or arrival resulting from any sort of delay. For example, Flight 1234 from LAX to SFO is delayed due to a mechanical issue, which requires 25 minutes of maintenance. JEP Airlines sends an Estimate Times message to update the estimated time of departure (etd). They also include a new estimated time of arrival (eta) within the message.

3.10.1.2 Update estimates from new flight plan calculation

This message can also be triggered from a change in the flight plan calculation. For example, a strong headwind for a flight leg between LGA and LAX changes the estimated time en route for the flight. A new flight plan is published using message DP001 which adds one hour to the original flight plan. JEP Airlines sends an Estimate Times message to update the estimate time of arrival for the flight.

3.10.1.3 Update estimates from departure data

This message can also be used to update estimates based on when the aircraft actually departs (Out or Off). For example, Flight 1234 from DEN to ORD leaves the gate (Out) ten minutes late due to weight and balance issues. The new Out time is then used to calculate a new ETA. JEP Airlines then sends the Estimate Times message to publish the new ETA.

3.10.1.4 Update estimates due to airborne delay

This message can be used to update estimates due to airborne delays. For example, severe weather has caused a number of flights to divert from nearby airports to SFO. When nearing SFO, Flight 1234 from LAX is told to engage in a holding pattern from twenty minutes. The pilot reports this to JEP Airlines, who then sends an Estimate Times message to update the ETA.

3.10.1.5 Additional Notes

• Some carriers calculate all of their flight plans first thing in the morning. As weather and airport conditions change through the day, the Estimate Times message can be sent to fine tune the estimated schedules.
• The etd, eto, eon, and eta fields are listed as Optional because different systems utilize different metrics (out versus off, and on versus in). Note, however, that most systems do not display the ETO and EON data.

3.10.2  Message System Flow

This message interacts with the systems as shown in Figure 18.

Figure 18. OC012 message system flow

3.10.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.11 OC013 - Next Information

3.11.1  Message Overview

This message is used to indicate a time when additional information about delays or flight statuses are expected to be communicated. This message may also contain a delay reason code.

3.11.1.1 Mechanical delays

This message can be used to communicate delays related to mechanical issues.

For example, a fluid is found leaking from the aircraft assigned to Flight 1234 from Denver to Chicago. The maintenance crew determines that it will take 30 minutes to diagnose the problem. They send a Next Info message for 30 minutes, at which time they expect to have a more detailed estimate for the required work. At the end of the thirty minutes, they have a diagnosis and additional estimate for the required work. They send another Next Info message for another hour. At the end of that hour, the maintenance issue is resolved and the flight can proceed to its next destination.

3.11.1.2 Next info for next departure

This message can also be used to communicate the Next Info point for a down-leg flight.

For example, Flight 1234 enters a holding pattern outside of Chicago due to severe winter weather. Because the pilots do not know when they will land, they call down to JEP Airlines and discuss the situation. JEP Airlines decides to send a Next Info message for the next flight leg’s departure time (ORD to LGA).

Note: This case is not common. Typically, carriers will simply send an Estimate Times message under these circumstances.

3.11.1.3 Additional Notes

3.11.2  Message System Flow

This message interacts with the systems as shown in Figure 19.

Figure 19. OC013 message system flow

3.11.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.12 OC014 - Arrival

3.12.1  Message Overview

This message is used when updating both the actual On and In times of a flight leg at the same time.

Although ACARS sends distinct messages for On and In events, both On and In are sent in one message when manually communicating this information using the Arrival message. Use the “Is ACARS” field in the case where the ACARS system logs the event, but the official record is entered manually.

3.12.1.1 Additional Notes

• Some airlines may post the On when landing in airports with long taxi times. This communicates that the passenger has landed, but has not yet arrived at the gate.

3.12.2  Message System Flow

This message interacts with the systems as shown in Figure 20.

Figure 20. OC014 message system flow

3.12.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.13 OC015 - Off

3.13.1  Message Overview

This message is used when updating the Off time of a flight leg. Off is the “wheels up” time, or actual takeoff time. If the message is an ACARS generated message, the actual trigger event is often the weight coming off the wheels. If the message is a non-ACARS message, it is generally triggered by the entry of this data into some system by a user. While the ETA is not required, it is highly encouraged this is sent with an Off message.

3.13.2  Message System Flow

This message interacts with the systems as shown in Figure 21.

Figure 21. OC015 message system flow

3.13.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.14 OC016 - On

3.14.1  Message Overview

This message is used when updating the On time of a flight leg. On is the “wheels on” time, or actual landing time. If the message is an ACARS generated message, the actual trigger event is often the weight coming on the wheels. If the message is a non-ACARS message, it is generally triggered by the entry of this data into some system by a user. While the ETA is not required, it is generally encouraged this be sent with an On message.

3.14.2  Message System Flow

This message interacts with the systems as shown in Figure 22.

Figure 22. OC016 message system flow

3.14.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.15 OC017 - Departure

3.15.1  Message Overview

This message is used when updating both the Out and Off times of a flight leg at the same time. While the ETA is not required, it is highly encouraged this is sent with a departure message.

Although ACARS sends distinct messages for Out and Off events, both Out and Off are sent in one message when manually communicating this information using the Departure message. Use the “Is ACARS” field in the case where the ACARS system logs the event, but the official record is entered manually.

3.15.1.1 Additional Notes

• This message can also capture the movement after push (map) data. This value reports the time after Out and before Off.

3.15.2  Message System Flow

This message interacts with the systems as shown in Figure 23.

Figure 23. OC017 message system flow

3.15.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.16 OC018 - Change Flight Leg Identifier

3.16.1  Message Overview

This message is used to change the flight identifier for a flight leg. Use this message to change a flight leg’s flight key rather than canceling and recreating the flight. 

3.16.1.1 Special Case: Changing the Flight Key for a New Date of Departure

Every flight key includes the flight origin date. This is the date of departure for the first leg of a flight. If the first leg needs to be rescheduled to another day, then you must first send the Change Flight Leg Identifier message for each leg of the flight to establish a new flight key. If this message is not sent, then you would have an incorrect flight key—one which shows the flight originating on the wrong day. Additionally, you could experience a duplicate flight key for the same flight leaving the next day. After sending the Change Flight Leg Identifier message, you can safely reschedule the flight. 

For example, the first leg of Flight 1234 from LAX to SFO is scheduled to depart on 12 DEC at 2100. The flight key for this original leg is JP 1234 12DEC LAX. Weather at LAX delays that flight three hours and five minutes, making the new departure time 0005 on December 13. Because the flight origin date (12DEC) is no longer correct, JEP Airlines must send a Change Flight Identifier Message to update the flight origin date in this and every down-leg flight. The new flight key for the first leg is JP 1234 13DEC LAX.

3.16.1.2 Changing the Flight Number

This message can also be used to change a flight number.

Some airlines reserve specific blocks of flight numbers for certain types of flights. For example, JEP Airlines uses flight numbers 2000-2999 for all non-revenue positioning flights and flight numbers 3000-3999 for all charter flights. On December 12, a corporate customer requests a flight from LAX to SFO on any available flights. Flight number 2222 was already scheduled as a positioning flight from LAX to SFO. JEP Airlines changes that flight number to 3333 to designate it as a charter flight. This enables JEP Airlines to quickly repurpose an existing flight without having to cancel the original flight and create a new one for the new purpose.

This message can also be used to rename flight numbers that were incorrectly entered upon creation. Again, this is easier and more efficient than canceling the flight and creating a new one with the correct flight number.

3.16.1.3 Additional Notes

3.16.2  Message System Flow

This message interacts with the systems as shown in Figure 24.

Figure 24. OC018 message system flow

3.16.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.17 OC020 - Air Return

3.17.1  Message Overview

This message is used when an aircraft performs an air return. An air return is a special type of diversion where the aircraft returns to the point of departure. When an application creates the continuation leg, the operational suffix field is used to uniquely identify the flight.

An operational suffix is included in the flight key to ensure that each flight key is unique. By law, each flight leg must possess a unique flight key consisting of the airline code, flight number, flight origin date, and point of departure. In situations where an air or ground return is required for one of these legs, the operational suffix field is required to distinguish one flight leg from another.

For example, flight number 1234 takes off from LAX at 2100 on December 12 and is forced to make an air return for mechanical reasons. The flight key for this original leg is JP 1234 12DEC LAX.  The ground crew quickly fixed the mechanical issue and the flight takes off at 2200 on December 12. This second flight has the same airline code, flight number, flight origin date, and point of departure as the first departure attempt. The operational suffix, for example A, is then required to distinguish between the first and second takeoff. The complete flight key for the second departure would then be JP 1234 12DEC LAX A.

Note: Jeppesen reserves the lower alphabet (A through F) for air and ground returns. Flights can experience both air and ground returns for the same leg; in these cases, increment the character for each return. For example, after an air return, the flight number would be 1234A. If that same flight leg had to perform a subsequent ground return, the next attempt would be 1234B.

3.17.1.1 Air return due to mechanical issue

Most air returns are due to mechanical issues and can happen any time from takeoff to the time the plane passes the halfway point to the nearest reasonable airport.
For example, Flight 2233 from LAX to HNL departs over the Pacific Ocean. An hour into the flight the pilots register a problem with the fuel. Because HNL is another 2 hours away, the point of origin (LAX) is still the closest airport. The pilots turn around and perform an air return at LAX. A continuation leg is automatically created for the next attempt to HNL.

3.17.1.2 Additional Notes

• An operational suffix must be used when creating the continuation leg. Failure to assign an operational suffix would result in duplicate flight keys.
  Jeppesen reserves the lower alphabet (A through F) for air and ground returns. Flights can experience both air and ground returns for the same leg; in these cases, increment up the alphabet for each return. For example, after an air return, the flight number would be 1234A. If that same flight leg had to perform a subsequent ground return, the next attempt would be 1234B.
• Air returns are typically due to mechanical or passenger issues. They rarely result from weather. In the case of bad weather at the destination, a Divert would be used.
• Note that certain information is required for an air return. Either the On time or estimated on time is required so that the tower knows when to expect the return. The point of arrival (POA), however, is not required, because in this case it is the same as the point of origin.

3.17.2  Message System Flow

This message interacts with the systems as shown in Figure 25.

Figure 25. OC020 message system flow

3.17.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.18 OC021 - Ground Return

3.18.1  Message Overview

This message is used when an aircraft performs a ground return. A ground return is a special type of diversion where the aircraft returns to the point of departure without leaving the ground. When an application creates the continuation leg, the operational suffix field is used to uniquely identify the flight.

An operational suffix is included in the flight key to ensure that each flight key is unique. By law, each flight leg must possess a unique flight key consisting of the airline code, flight number, flight origin date, and point of departure. In situations where an air or ground return is required for one of these legs, the operational suffix field is required to distinguish one flight leg from another.

For example, flight number 1234 takes off from LAX at 2100 on December 12 and is forced to perform a ground return for mechanical reasons. The flight key for this original leg is JP 1234 12DEC LAX.  The ground crew quickly fixed the mechanical issue and the flight takes off at 2200 on December 12. This second flight has the same airline code, flight number, flight origin date, and point of departure as the first departure attempt. The operational suffix, for example A, is then required to distinguish between the first and second attempts. The complete flight key for the second departure would then be JP 1234 12DEC LAX A.

3.18.1.1 Ground return due to mechanical issue

Ground returns occur after the aircraft leaves the gate and before takeoff.

For example, Flight 2233 performed an air return from its LAX to HNL leg, received maintenance, filed a continuation leg, and pushes away from the gate as Flight 2233A. While taxiing to the runway, however, the pilots hear a clanking sound beneath the aircraft. They send the Ground Return message and ground return to the gate to discover that the cargo doors were not secured.

Note that because in this example the ground return was preceded by an air return, the operational suffix will be incriminated to “B” for the next attempt.

3.18.1.2 Additional Notes

• An operational suffix must be used when creating the continuation leg. Failure to assign an operational suffix would result in duplicate flight keys.
  Jeppesen reserves the lower alphabet (A through F) for air and ground returns. Flights can experience both air and ground returns for the same leg; in these cases, increment up the alphabet for each return. For example, after an air return, the flight number would be 1234A. If that same flight leg had to perform a subsequent ground return, the next attempt would be 1234B.
• Ground returns are typically due to mechanical or passenger issues. They rarely result from weather. In the case of bad weather at the destination, a Divert would be used.
• Note that certain information is required for a ground return. Either the In time or estimated time of arrival (eta) is required so that the gate knows when to expect the return. The point of arrival (POA), however, is not required, because in this case it is the same as the point of origin.

3.18.2  Message System Flow

This message interacts with the systems as shown in Figure 26.

Figure 26. OC021 message system flow

3.18.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.19 OC022 - Delay

3.19.1  Message Overview

This message is used to communicate one or more delays affecting a flight leg. This message overlays any previously sent delays. Delays are posted as actual durations. For departures, delays are the actual differences between the scheduled time of departure (std) and Out. For arrivals, delays are the actual differences between the scheduled time of arrival and In.

3.19.1.1 Posting delay for any reason

This message can be used to communicate any actual information related to delayed departures or arrivals. For example, Flight 1234 from LAX to SFO is delayed due to a mechanical issue. After 30 minutes the aircraft is cleared for takeoff and pushes away from the gate. The Delay message is sent specifying the actual departure delay value and reason.

3.19.1.2 Additional Notes

• The departure delay and arrival delay are listed as optional because different markets monitor different metrics. For example, US carriers must report their arrival delays to the Department of Transportation, where as European carriers report on departure delays.
• Delay messages are posted AFTER the departure or arrival, so that they can accurately report actuals. Some airlines hold briefing reports to determine the true cause of delays: for example, crew, weather, maintenance. The report-collection process may take some time; therefore these airlines may not publish delay information for a day or two after the actual flight.
• The repeating group in the message allows airlines to assign multiple reasons for the delay. For example, an airline might track that a 25 minute departure delay can be partitioned into the following: Weather (10 minutes), Crew (5 minutes), and Maintenance (10 minutes).

3.19.2  Message System Flow

This message interacts with the systems as shown in Figure 27.

Figure 27. OC022 message system flow

3.19.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.20 OC023 - Out

3.20.1  Message Overview

This message is used to update the Out time of a flight leg. This is sometimes referred to as the off-block time. It is defined by IATA as the time when the aircraft begins to move, either under its own power or by external power. If the message is an ACARS generated message, the actual trigger event is often either the locking of the aircraft doors or the release of the brake. If the message is a non-ACARS message, it is generally triggered by the entry of this data into some system by a user, possibly at the gate. While the ETA is not required, it is highly encouraged this is sent with an out message.

3.20.2  Message System Flow

This message interacts with the systems as shown in Figure 28.

Figure 28. OC023 message system flow

3.20.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.21 OC024 - In

3.21.1  Message Overview

This message is used when updating the In time of a flight leg. In is the “on the gate” time, or actual arrival time. If the message is an ACARS generated message, the actual trigger event is often the door open time. If the message is a non-ACARS message, it is generally triggered by the entry of this data into some system by a user.

3.21.2  Message System Flow

This message interacts with the systems as shown in Figure 29.

Figure 29. OC024 message system flow

3.21.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.22 OC025 - Flight Lock

3.22.1  Message Overview

When an airline has determined that a flight needs potential investigation, they may choose to lock down the data so that no one can change the information. OC025 is typically sent from the Operations Control system to the dispatch system so that the user interface will not allow the flight to be accessed or altered.

3.22.2  Message System Flow

This message interacts with the systems as shown in Figure 30.

Figure 30. OC025 message system flow

3.22.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.23 OC026 - Flight Assignment Data

3.23.1  Message Overview

This message is used to communicate flight assignment data, including aircraft information and crew assignment data, to a system external to the AOCi. This message is typically sent following updates to the schedule planning and crew management systems.

3.23.2  Message System Flow

This message interacts with the systems as shown in Figure 31.

Figure 31. OC026 message system flow

3.23.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.24 OC027 - Post Flight Actuals

3.24.1  Message Overview

Following the completion of a flight, the OC027 message can be used to communicate the ACTUAL flight information between systems within the AOC as well as external products. Information includes actual arrival and departure times, crew assignments, and fuel consumption.

3.24.2  Message System Flow

This message interacts with the systems as shown in Figure 32.

Figure 32. OC027 message system flow

3.24.3 Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.25 OC028 - Post Flight Summary Report

3.25.1  Message Overview

Flight summary information is often needed following a flight or group of flights. For example, a billing system may require actual flight information to track and analyze flight operation costs. OC028 provides the "actual" data related to a flight or flights within a specified date range. This information can be published from an AOCi system such as Operations Control or from an external system to system consuming the data.

This message interacts with t

3.25.2  Message System Flow

he systems as shown in Figure 33.

Figure 33. OC028 message system flow

3.25.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.26 OC029 - Request Diversion

3.26.1  Message Overview

This message is similar to OC005 Divert Flight Leg, but contains more customer-specific fields. Customers should use OC005 unless advised by a Jeppesen deployment expert to use this message instead.

See OC005 for a description of diversion scenarios.

3.26.2  Message System Flow

This message interacts with the systems as shown in Figure 34.

Figure 34. OC029 message system flow

3.26.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.27 OC030 - Fuel On Board at Enroute Positions

3.27.1  Message Overview

This message is used to send a message originating from an ACARS message through AOCi to a Dispatch or Operations Control system. The message communicates the fuel on board at various points in the flight. The typical information flow is as follows:

1. Aircraft sends an ACARS message.
2. ACARS message is retrieved by a receiver on the ground (for example, Arinc).
3. Message is forwarded to external system, which translates the information into the AOCi OC030 message format.
4. OC030 is forwarded through AOCi to the receiving Dispatch or Operations Control application.

3.27.2  Message System Flow

This message interacts with the systems as shown in Figure 35.

Figure 35. OC030 message system flow

3.27.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.28 OC031 - Gate Assignment

3.28.1  Message Overview

This document is currently in draft - details and description of functions will follow.

3.28.2  Message System Flow

This document is currently in draft - details and description of functions will follow.

3.28.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.29 OC032 - Ad Hoc Create Flight Leg

3.29.1  Message Overview

This document is currently in draft - details and description of functions will follow.

3.29.2  Message System Flow

This document is currently in draft - details and description of functions will follow.

3.29.3   Message Details

The following table provides details on the message version and includes links to the message’s technical specification.

3.30 OC033 - Dispatcher Lock

3.30.1  Message Overview

This document is currently in draft - details and description of functions will follow.

3.30.2  Message System Flow

This document is currently in draft - details and description of functions will follow.

3.30.3   Message Details

The following table provides details on the message version and includes links to the message's technical specification.

3.31 OC034 - Aircraft Lock

3.31.1  Message Overview

This document is currently in draft - details and description of functions will follow.

3.31.2  Message System Flow

This document is currently in draft - details and description of functions will follow.

3.31.3   Message Details

The following table provides details on the message version and includes links to the message's technical specification.

3.32 OC035 - Fuel Tankering Advice

3.32.1  Message Overview

This document is currently in draft - details and description of functions will follow.

3.32.2  Message System Flow

This document is currently in draft - details and description of functions will follow.

3.32.3   Message Details

The following table provides details on the message version and includes links to the message's technical specification.

3.33 OC036 - Request Complete Flight Key

3.33.1  Message Overview

This document is currently in draft - details and description of functions will follow.

3.33.2  Message System Flow

This document is currently in draft - details and description of functions will follow.

3.33.3   Message Details

The following table provides details on the message version and includes links to the message's technical specification.

3.34 OC037 - Completed Flight Key

3.34.1  Message Overview

This document is currently in draft - details and description of functions will follow.

3.34.2  Message System Flow

This document is currently in draft - details and description of functions will follow.

3.34.3   Message Details

The following table provides details on the message version and includes links to the message's technical specification.